如何以团队的方式进行Git（附代码）

在过去的几年里，当我和我的客户一起工作时，我看到建立一个常识性的git工作流程对于一个团队变得富有成效是多么的关键。我经历过几种情况--比如在一个由开发人员组成的团队中工作，在一个刚刚从另一个版本控制系统过渡过来的成熟团队中工作，或者作为一个团队的新成员，在没有git实践的情况下，我想快速上手--在这种情况下，让每个人都在一个git框架下遵循常识和最佳实践是有意义的。

在我经历了几次这样的挣扎之后，我想写下我对团队的git所学到的东西，这可能有助于你将你的团队统一在一个工作流程上。如果这篇博文对你来说太长了，你可以在 "午餐和学习 "中与你的团队一起阅读，并将最重要的内容浓缩在git工作流程的小抄中。如果你自己想出了这个小抄，你的团队就会拥有它，并可以根据你的具体情况，对它进行反复的学习。

注意：下面的内容只传达了我在一个5-25人的团队中使用git作为版本控制系统的经验。你在这里读到的东西都不是一成不变的，但我看到一旦这个工作流程（或任何其他工作流程）在一个组织中建立起来，就会有富有成效的团队。如果你在你的公司遵循不同的工作流程，我很想听听你的想法。

基本上，以团队形式工作的git有三种分支：

git 工作流程中可以有多个特性分支，但只有一个主分支和一个暂存分支。中转分支的命名各不相同 -- 例如，我曾见过一个中转分支被称为develop和development分支。主分支的名字来自 git 本身。特性分支的名称可以是你的团队所认同的任何命名规则。我曾见过这样的情况：

通常人们也会对特性分支使用feat/YMC-1634这样的命名，以便将它们直接链接到scrum/kanban/...板中的票据。请注意，特性分支不仅用于特性开发，还可以用于错误修复和其他事情。特性分支是所有实现的地方，而staging和master分支只用于发布你的应用程序。在下文中，我将使用 ＜branch_name＞ 来表示这些分支中的任何一个。

现在有几个 git GUI 应用程序，可以让你免于使用命令行。然而，最后我发现，熟悉git的命令行总是最好的；要真正知道哪些命令是在引擎盖下使用的，或者要解决git的问题，而GUI工具是不透明的。最直接的命令是：

前一个命令显示你在staged和unstaged模式下修改的文件--重要的是：熟悉这些模式--而后一个命令则显示你的git历史。有时，如果你搞砸了什么，想跳回过去，git reflog可以救你一命。在下面的git工作流程中，我们的目标之一是保持一个排列整齐的git历史，可以用git log 。

主分支和暂存分支只创建一次，只要项目存在就一直保留。相比之下，特性分支是在特性开发期间创建的。它们会被合并到暂存分支中，最后暂存分支会被合并到主干分支中，以便发布新的应用程序。中间的暂存分支用于CI/CD准备下一个版本，同时也可以在线看到应用程序的暂存版本（如staging.my-domain.com）。

有两个基本命令：1）创建一个新的分支；2）检查一个可用的分支。

在项目生命周期之初，必须有人用必要的配置来设置主干分支和暂存分支（例如，不在主干/暂存分支上强制推送，PR模板，...）。此外，还需要特别为这两个分支设置CI/CD--但也包括后来的特性分支--以便在早期发现lint、测试或格式化问题。

如果你想检查一个只有在远程仓库才有的特性分支，因为一个团队伙伴已经创建并推送了它，但你却没有它的本地拷贝，可以打电话。

本质上，"fetch "可以使所有可用的分支与你的本地机器保持同步 -- 但不包括它们的提交，这需要另一条 pull 命令。稍后会有更多关于这方面的内容。如果你想删除一个分支，你可以1）在本地删除它，或者2）远程删除。

后者要小心，因为很可能你想在删除分支之前将其合并到staging。总之，当你完成并合并了一个特性分支后，你可以自由地在本地或远程处置它。

使用特性分支进行的最直接的特性开发看起来像下面这样。首先，用git checkout -b 签出新的特性分支。接下来，你实现你的代码，并使用下面的命令使你的修改对远程仓库中的所有人可用。

git add . ，将所有修改/添加/删除的文件移到暂存区，供下次提交使用，你可以使用git add的变体，只将修改的文件中的一个子集移到暂存区。如果你遵循原子提交策略，这很有帮助。例如，我喜欢用git add -u ，将所有已修改但不是新的文件移到暂存区。

如果你在这中间使用git status ，你会看到有暂存和未暂存的文件。同时git也会给你指示，将文件从1）staged移到staging，从2）staging移到未改变的文件。

把文件移到暂存区后，每一个文件都会和你的提交信息一起提交。提交信息有不同的命名方式，你遵循哪种命名方式并不重要，重要的是你作为一个团队要有一个统一的标准。我喜欢用下面的命名规则。

可以有以下几种类型：

因此，一个提交信息可以是下面这样的：

如前所述，你不需要遵循这个命名规则，但为了让你的团队中的每个人都在同一起跑线上，自己要对准一个命名规则。这适用于提交信息，比分支命名更重要。

最后但并非最不重要的，在你添加并提交了你的修改后，用git push origin 推送所有东西到你的远程仓库。这一步是可选的，因为你可以先积累提交，然后再推送所有的修改，让你的团队可以使用。

无论你在哪个分支（分期/特性）工作，有时你需要用远程分支的修改来更新这个分支的本地版本，因为有人向它推送了更新。在你开始更新该分支之前，请遵循这些可选的步骤:

然后你就可以开始拉取最新的修改了。我的建议是始终使用 rebase，将你的提交放在远程分支的提交之上:

如果你修改的文件也是远程提交的，那么在回溯过程中可能会遇到合并冲突。如果发生这种情况，请解决该文件的冲突，然后在命令行中继续执行。

在最坏的情况下，可能发生的情况是，你自己的每一个提交都与远程分支的提交发生了冲突而被重新建立。如果是这种情况，请重复之前的步骤。如果你的拉取回溯出了问题，你可以随时中止它：git rebase --abort 。

拉取重构完成后，你的所有提交应该被列在远程分支的提交之上。如果你之前把修改藏起来了，你可以用以下方法再次应用它们。git stash apply.你的分支应该是最新的了，远程分支的修改和你自己的修改都在上面了。

一旦你开始在某个特性分支上工作，你可能希望保持该分支与暂存分支的更新，以防其他人将他们的特性分支合并到暂存中。那么，什么时候要让特性分支与暂存分支保持同步？

按照这个git工作流程，让您的特性分支与暂存分支保持同步。

如果你之前推送过你的分支到远程仓库，你必须强制推送你的修改，因为你的分支的历史在与暂存分支重合期间发生了变化。

但要注意强行推送的问题。如果其他人在这期间在该分支上做了修改，强行推送会强行覆盖所有这些修改。

拉取请求（PR）会将你的特性分支的所有修改合并到暂存分支。之后，你可以在本地和远程删除你的特性分支。尽管没有PR也可以进行合并，但PR可以让其他人在GitHub或Gitlab等平台上审查你的特性。这就是为什么最好的做法是，一旦你在这个分支上完成了实际功能的实现，并将所有东西推送到远程仓库，就为你的特性分支开一个 PR。git 的工作流程如下。

如果你的特性分支一切正常，请继续采用以下方式。

恭喜你，你已经把你的特性分支合并到了staging中，并在此过程中保持了所有内容的更新。现在，为你的下一个特性分支冲洗并重复这个git工作流程。如果你在git工作流程中搞砸了什么，不妨看看这个用git恢复几乎所有东西的教程。

前面的git工作流程是基于git的rebase功能来保持你的分支是最新的，并将它们合并到各个分支中。通过使用 rebase，你将总是在其他团队成员的修改之上应用你的修改。这样一来，你的git历史将总是讲述一个线性的故事。下面的命令将帮助您保持特性分支的git历史的整洁。

其中一些git提交会改变您的本地提交历史。如果您之前将特性分支推送到了远程仓库，您就必须强制推送这些改动。请再次注意，不要用强制推送覆盖团队成员的修改。

我很想知道其他的git工作流程，如果有的话，请在评论中告诉我。如果你有任何git的最佳实践或问题需要补充，那么请让我们知道它们。毕竟，我希望这个攻略能帮助你为你的团队建立一个使用git的工作流程。从长远来看，它将使你和你的团队在一个常识性的流程上保持一致，从而提高工作效率。